…habe ich schon angeregt. Dieses Problem besteht eben an den Schnittstellen wenn man viele Gebiete zu einer großen Gebiet zusammenfügt. Wenn man das explizit seitz kommt ne nahtlose plausible Karte raus. Leider kann man diese Parameter nicht bis ins Maperitive Script durchreichen. Deshalb werde ich mal ein “kleines” Zwischenprogramm dranhängen. Ansonsten sieht das gut aus.
MfG
Achim
Ps: So sieht jetzt die Schnittstelle der Wege zwischen 2 getrennt gerendererten Kacheln aus (mittlere schwache Linie). Je nach Zoomstufe wird der Text zB.:Kentheimer Berg nur halb dargestellt und an der Kachelgrenze abgeschnitten. So kann ich mit ner automatisierten Generierung beliebig große Karten generieren
die 0.3 Grad größer ausschneiden bringt in diesem Fall nichts, da man genau die Kachelgrenzen einhalten muß um die “verschiedenen” Teilgebiete zu einer GANZEN Tilestruktur zusammenzubauen.
Mit dem größer Ausschneiden ist das aber ok, wenn man nur einen Ausschnitt betrachtet! Ich möchte aber ein große Map aus einzelnen Kacheln zusmmenbauen.
Schneidet eine Zoom 8 Kachel aus mit 0,2 Grad Rand
In Maperitive darft ich aber nur
set-geo-bounds 8.43751,48.92251,9.84374,49.83797
haben um nur die komplette Kachel zu bekommen.
Wenn ich das mit den Nachbarkacheln ganauso mache bekomme ich die Kacheln ohne Überganseffekte (abgeschnittener Text usw.).
Nur stellt sich das Problem das ich eine Batchdatei mit osmconvert-Auschnitt-aufruf und Maperitive-aufruf erstellen muß und auch noch das Script erstellen muß mit der genauen BBOX für die Kachel!
MOBAC übergibt ja “nur” die bbox und in der batch kann man nicht Gleitkomma rechnen.
Ich bastel mir grad ein MortScript zurecht das dies alles Erledigt - was ja nicht besonders Schwer ist da nur recht einfache Rechnungen und ein bischen schreiben in Datein gefordert ist.
Ich hatte nur gehofft das osmconvert die europe.pbf direkt schneiden kann - bevor ich da großes in das MortScript stecke und es dann doch ändern muß (sollte schon etwas flexibel sein!)!
Braucht ihr aber nicht, mir macht es ja Spaß. Jeder von uns leistet seinen Beitrag zum Kuchen “OSM”, einer programmiert, andere generieren super Karten und viele Mappen einen Quadratkilometer nach dem anderen.
Vielleicht kriegst du das auch per Integer-Berechnung hin. osmconvert rechnet inter ja auch (fast) nirgends mit Fließkommazahlen, sondern nur mit Festkommazahlen. 49 Grad nördliche Breite werden intern als 490000000 gespeichert. Das PBF-Format macht das übrigens auch so.
Also… man könnte den Dezimalpunkt irgendwie rauswerfen und wenn man ihn dann braucht, wieder einfügen. Das bedeutet natürlich einiges an geschickter Stringmanipulation, aber dafür sollten die Windows-Bordmittel reichen.
das ist richtig, aber dann wird doch beim rendern in einigen Zoomstufen der Text an der Kachelgrenze halbiert (aber noch nicht verifiziert). Aber es gibt da wohl ein neues Feature in Maperitive laut Igor
In der später gerenderten Nachbarkachel tauch durch den Rand ja der Text der über die Kachelgrenzen geht ja auch auf und das fehlende wird ergänzt!
währe auch schlimm wenn ich die Nachbarkachel rendere und Maperiative verschieb den Text weil an Kachelgrenzen (set-geo-bounds ) gelegen!
Klappt bei mir recht gut nur Ludwighafen und Mannhein ist da ein Problem zwischen Zoom 8 und 11 je nach Zoomstufe kommt mal Ludwigshafen oder Mannheim und das in der jewiligen Kachel verschieden.
F:\convert>gcc -c -m64 osmconvert_new.c
osmconvert_new.c:1:0: sorry, unimplemented: 64-bit mode not compiled in
abgebrochen. Jetzt ist die Frage ob das am Quellcode liegt (hier sind die Windows Ausnahmen ja immer mit win32 ausgeführt) oder aber am gcc compiler oder gar den Bibliotheken.
Ok wenn du so sagst, dann soll es so sein. Osmconvert ist also in c geschrieben. Da g++ immer auf Fehler hinweist.
Inzwischen hatte ich auch noch andere Erklärungen gefunden. gcc sei für alle Sprachen zuständig. Auch Java und Fortran. Allerdings hat mich verwundert das g++ den Virenscanner herausfordert und außerdem noch mit 4 Fehlern abbricht.
Dein Compiler kann kein x86_64, sondern “nur” 32 Bit.
Bei der Ausgabe von meinen (64 Bit)
gcc -v
erscheint u. a.
–with-arch-32=i586
also kann er auch (wenn auch die entsprechenden Bibliotheken vorhanden sind) 32 Bit kompileren (mittels Parameter “-m32”)
Mein Posting wäre angesichts der sich hier entwickelten Diskussion vielleicht wirklich besser in einem neuen Thread aufgehoben.
Wenn es nicht hierher paßt, kopiert es bitte für Eure Antwort in einen einen neuen Threadstart und antwortet hier nur mit dem Linkverweis. - - - Danke!
Meine Überlegungen:
Auch mit 64bit/8GB rennt sich Maperitive z.B. mit NRW fest, wenn man das osm-File mehrfach ungefiltert verarbeitet.
Mobac kenne ich (noch) nicht. Daher kann ich zu den oben beschriebenen Ideen vorerst nichts sagen. Aber vielleicht passen meine Überlegungen ja trotzdem irgendwie dazu.
Mir geht es um folgendes:
Wenn man für Maperitive Renderrules erstellt, definiert man in der Sektion “features” die in der Sektion “rules” zu berechnenden Objekte.
Da aus der *.osm-Datei lediglich die in der Sektion “features” aufgerufenen Tags benötigt werden, liegt doch die Idee nahe, eine Eingabemaske zu programmieren, aus der
ein Filter-Script für osmfilter abgeleitet wird
die Sektion “features” abgeleitet wird
Da ich vom Programmieren keine Ahnung habe, kann ich nicht beurteilen, ob dieses Ansinnen grundsätzlich überhaupt möglich ist oder ob das grundsätzlich Handarbeit bleiben muß.
Im Moment hab ich erst einmal daran gefeilt, eine rules-Datei so aufzubauen, daß man beim Lesen des rules-Scripts sieht und versteht, was da passiert bzw. passieren soll.
Bei dem Arbeitsschritt, dazu passend einen Filter mit osmfilter oder osmconvert aufzusetzen, bin ich noch nicht. Doch so ein Filter ist zwingend notwendig, wenn Bundesländer wie NRW am Stück aus kombinierbaren Layern erstellt werden sollen.
Notwendig ist der aus folgendem Grund:
Wenn aus einem ungefiltertem Datensatz eine Karte erzeugt wird, legt Maperitive eine Menge Daten im Speicher ab.
Diese Karte ist aber möglicherweise “nur” die “Unterlage” für eine ganz bestimmte Art von Informationen.
Beispielsweise könnte man auf dieser Grundkarte zusätzlich ein bestimmtes Routennetz abbilden wollen oder eine spezielle Gruppe von POIs.
Natürlich könnte man Rules schreiben, die von vorn herein die gewünschte Kombination erzeugen. Doch das wäre nicht sehr flexibel bei der späteren Kartenerstellung.
Verschiedene “Overlay-Rules” könnte man dagegen als “Baukasten” benutzen, da Maperitive über die “Unterlage” weitere durchsichtige Layer legen kann.
Und nun das Problem: Zieht man die Daten alle aus derselben *.osm-Datei, summieren sich anscheinend die Daten im Speicher (werden immer wieder neu dort abgelegt) und dann sind auch größere unter 64-bit laufende Speicherkapazitäten früher oder später erschöpft. Um da mehr Spielraum (im doppelten Sinne ) zu gewinnen, plane ich, für jede rules-Datei einen passenden Filter zu erstellen, damit Maperitive nur die Daten im “Futternapf” findet, die es verarbeiten soll und nicht auch noch all die anderen “hamstert”, die es gar nicht benötigt. Per script bekomme ich das mit Sicherheit hin. Dennoch interessiert mich, ob es möglich ist, dafür eine GUI (ist das so etwas? http://de.autohotkey.com/docs/commands/Gui.htm / http://de.autohotkey.com/ ) zu programmieren, die ausgewählte Tags sowohl an den Filter als auch an das rules-Script weiter gibt? Oder ist das zu kompliziert? (Ich habe keine Ahnung, wie so etwas geht.)
@ Marqs
Ich nehme mal an, daß osmfilter schneller (weil weniger komplex arbeitend) ist, als osmconvert.
Solange ein von der Geofabrik angebotener Datenauszug “paßt”, benötigt man die Schneidefunktionen mit --complete- ja nicht.l
Und wenn eine große Datei “kleingefiltert” wurde, läßt sie sich anschließend mit weniger Speicherverbrauch schneiden.
Habe ich das so richtig verstanden?
Oder arbeitet osmconvert im Prinzip genauso wie osmfilter, wenn man ausschließlich dessen Filterfunktionen nutzt?
Wenn es Unterschiede gibt, müße man ja beide Programme in eine eventuel machbare GUI einbinden.
Wird wohl so nicht gehen (z.B. darstellung in welcher Zoomstufe wie und evtl. UND / OR / NOT Verküpfungen?) - allerdings könnte man umgedreht gehen die Rules auslesen und die osmfilter damit befüllen.
Eine Frage ist mir bei osmfilter gekommen : Wie ist das mit den hier schon geliebten MP’s ?
Berücksichtigt es auch sowas wie complex-ways da mittlerweile viele MP z.B: das forest nur moch im MP haben und die Ways ganz andere Tags aufweisen können !
Währe ja das KO fürs MP da keine Ways mehr vorhanden sind nach dem Filtern!
Mit den verschiedenen Overlay die du angedacht hast kann man verschiedene Lösungsansätze sehen!
1: Ich lasse die verschiedenen Karten in Maperitive renden …
2: Ich rendere eine Grundkarte und verschiedene Overlays getrennt in Maperitive und setzte die Overlay wie gewünscht in MOBAC zu eine Karte zusammen!
Vorteil von 1 immer aktuelle Kartendaten da immer komplett gerendert Nachteil : Jede kombination muß ich neu Rendern
Vorteil von 2 das doch recht rechenintensive rendern der Grundkarte muß nur einmal gemacht werden die Overlaykarten werden da wenige Daten sehr schnell und man große Gebiet (ganz D geht schon) rendern. In MOBAC kann man munter die Overlay kombinieren
Nachteil : Sehr viele Kacheln und Festplattenspeicherverbrauch
ich hab noch nicht alles gelesen und verstanden, aber ich antworte schon mal auf die direkten Fragen.
Jein.
Soweit ich weiß, filtert die Geofabrik mit der Funktion CompleteWays. Ich vermute, dass dadurch die grenzüberschreitenden Multipolygone nicht zwangsläufig komplett enthalten sind. Irgendwer hat mal von einem Waldproblem an der tschechischen Grenze geschrieben.
Man müsste dazu mal Frederik befragen.
Nein. Der Hauptspeicherverbrauch von osmconvert hängt bei den Schneidefunktionen nicht von der Dateigröße ab. Deswegen kann man auch mit einem kleinen PC das Planet-File schneiden. Probleme gibt es nur mit den Funktionen --complete-ways und --complex-ways, weil diese in der Eingabedatei “springen”. Und dieses Springen (praktisch ein Vor- und Zurückspulen) funktioniert bei osmconvert unter 32-Bit-Windows derzeit nur bis zu einer Dateigröße von 2 GiB.
Aber vielleicht meinst du auch gar nicht den Hauptspeicher, sondern die Dateigröße. Dafür bringt das Filtern sicher eine Menge. Zusätzlich schadet es nichts, wenn man mit --drop-author die Autor-Informationen rauswirft.
Die Programme sind vom Code her ein bisschen ähnlich, aber von der Funktion her sehr unterschiedlich. Geschickt wäre es sicher, wenn man ein GUI entwickeln könnte, das beide Programme nutzen kann.
@viw:
Du hast Recht, die Windows-Ausnahmen stehen im Quellcode immer mit “WIN32”. Vielleicht geht das dann bei Win64 schief, und man müsste diese Abfragen ändern. Ich kanns leider nicht selber testen. Aber ich erinnere mich, dass es auch eine allgemeine Windows-Abfragemöglichkeit gibt, ohne die 32 hinten. Vielleicht bau ich besser die ein.
osmfilter filtert von oben nach unten. Das heißt: Wenn die Multipolygon-Relation selbst die gewünschten Tags hat (z.B. landuse=forest), dann werden alle Elemente dieser Relation behalten. Das gilt auch für die Unterelemente dieser Elemente, usw. Also bleiben alle enthaltenen Ways, deren Nodes. Sogar Relationen, die in der Multipolygon-Relation enthalten sind, bleiben ebenfalls mit allen ihren Bestandteilen.
Mir schweben beide Lösungsansätze vor (ohne Mobac bislang zu kennen).
Wenn ich das richtig verstanden habe, bietet Maperitive die Möglichkeit große Grafikdateien (ich glaube für Plotter) auszugeben. Ich habe nur noch nicht den Dreh raus, wie man die dann anzeigen läßt. Für die Erstellung solcher “Plotter-Dateien” ist die Idee gedacht, die Wunschkarte direkt in Maperitive zusammenzubauen.
Für eine Weiterverwendung in einem Programm, das mit austauschbaren Layern umgehen kann, ist dieses Vorgehen nicht sinnvoll.
Da macht es mehr Sinn nach dem Vorbild verschiedener Web-Karten thematisch gruppierte Kartenobjekte als separate Layer zu rendern.
Das müssen ja nicht nur POIs sein. Mit Hilfe dieser Layer läßt sich dann die Grundkarte variabel “füllen” und wenn es unübersichtlich wird, wählt man störende Layer wieder ab.
Genau das geht in Maperitive nicht. Was drin ist, ist drin. Wenn die Karte zu voll geworden ist, muß man Maperitive schließen und neu anfangen.
Welcher Weg für den Kartenbastler der richtige ist, hängt davon ab, wo man am Ende hin möchte.
Zwei gegensätzliche Anwendungen wären:
- eine großformatige Themenkarte z.B. für einen Schaukasten
- eine vielseitige Karte für irgendeine PC-Anwendung
In irgendeinen Speicher muß man zum Basteln großer Karten in jedem Fall investieren:
Arbeitsspeicher
Festplattenspeicher
Ist halt die Frage was man benötigt / was einem wichtiger ist.
Im Zweifel beides.
Ja, das wäre genau der Weg, den ich “zu Fuß” verfolge:
Erst mal mit einem kleinen von JOSM “hinterlassenen” Kartenausschnitt so lange probieren, bis die Auswahl in der Karte gut aussieht
und dann aus dem rule-Script abschreiben, was dazu gebraucht wird.
) zu gewinnen, plane ich, für jede rules-Datei einen passenden Filter zu erstellen, damit Maperitive nur die Daten im “Futternapf” findet, die es verarbeiten soll und nicht auch noch all die anderen “hamstert”, die es gar nicht benötigt. Per script bekomme ich das mit Sicherheit hin. Dennoch interessiert mich, ob es möglich ist, dafür eine GUI (ist das so etwas? 
